[レポート] ビジネスの意思決定を加速する BI on Snowflake 設計の勘所 #SnowflakeDB #SnowdayJapan

SNOWDAY JAPAN

#Snowflake

しんや

2023.03.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2023年02月14日(火)、ANAインターコンチネンタルホテル東京、ならびにオンライン配信のハイブリッド形式でSnowflakeのイベント「SNOWDAY JAPAN」が開催されました。

当エントリではその中で、ブレークアウトセッションとして開催された「ビジネスの意思決定を加速する BI on Snowflake 設計の勘所」のレポートをお届けします。

セッション概要

当エントリで扱うレポートのセッション概要は以下の通りです。

SNOWDAY JAPAN

[セッションタイトル]
ビジネスの意思決定を加速する BI on Snowflake 設計の勘所

[登壇者]
・三田泰正氏(Snowflake株式会社　セールスエンジニアリング本部　シニアセールスエンジニア)

[セッション概要]
BI ソリューションは Snowflake に接続するデータアプリケーションの 1 つであり、大規模なデータから意思決定に役立つさまざまなインサイトを得る目的で、数多くのお客様に活用されています。しかしながら、その価値を最大化するためには、高いパフォーマンスで大規模データを可視化することが不可欠です。本セッションでは、BI ソリューションの具体例として Tableau を取り上げ、Snowflake の接続方式やキャパシティプランニングといったパフォーマンスに影響を及ぼす設計の勘所について説明します。

セッションレポート

はじめに

本日のテーマは「SnowflakeとBI製品の連携、組み合わせ」。
メジャーな組み合わせではあるが、コストパフォーマンスを出そうとすると幾つか課題が出てくる。

Snowflake + BI製品のよくある課題

Snowflakeは数多くのBI製品と接続可能。接続自体はODBC/JDBC、またサードパーティコネクタ経由等で行う事が出来る。
ただ接続するのは簡単だがうまく使っていこうとするとSnowflake側に色々課題が出てくる。
- (1).コスト：BIからのクエリをSnowflake側で処理＝クエリの処理でウェアハウスを使用するため、想定以上にウェアハウスのコストが掛かる
- (2).ダッシュボードのパフォーマンスが出ない：ダッシュボードが開かない、フィルタ切り替えによる再描画に時間が掛かるなど。またピークタイムにアクセスが集中することでパフォーマンスが落ちる
Snowflake＋BIの組み合わせで高いコストパフォーマンスを実現するにはどうすれば良いか？
- コストは出来るだけ下げたい
- その上でパフォーマンスを向上させたい

コストパフォーマンスに効く設計ポイント

ライブと抽出

TableauからSnowflakeに接続する例 - 「ライブと抽出」の活用
ライブ接続(直接接続)
- ユーザー操作による描画の際はSnowflakeにクエリを発行→クエリ処理はSnowflakeウェアハウス側で実行
- 常に最新のデータがダッシュボードに反映＝都度クエリ発行処理がSnowflake側に対して掛かる
抽出接続
- データをTableau Desktop/Serverの"ローカル"に抽出・保存
- ユーザー操作による描画の際はその抽出データに対してクエリが発行される＝Snowflake側に負荷は掛からない
- ただし、最新データの反映には「抽出ファイルの更新」が必要
どちらを選択すべきか？
- 一長一短ある
- 二者択一では無く、データ更新の頻度や規模に応じて使い分ける
併用案

ダッシュボードのパフォーマンス問題

症状例
- 開くのに時間が掛かる
- フィルタ切替時の結果表示に時間が掛かる
ボトルネック
- 同時実行性能、または単体クエリの処理性能に帰結
- ピークタイム(始業時等)に多数のユーザーが実行する場合にのみ発生(同時実行性能の問題)
- ピークタイムやユーザー数の大小に関わらず常に問題が発生(クエリ処理や描画性能の問題)

パフォーマンスのボトルネック

そもそもBI(Tableau)とSnowflakeでどういった処理の流れがあるのか？を図示したのがこちら。(Tableau ServerからSnowflakeにリクエストがあった場合の例)
- ボトルネックになる場所は2箇所。1つはSnowflake側、もう1つはTableau側。
- Snowflakeではこれらのボトルネックに対する対応方法、ソリューションを説明していく

ウェアハウスの最適化

複数クエリの同時実行性能：マルチクラスターウェアハウスが有効。ユーザー数(実行クエリ)の増減に伴い、最大10クラスターまで自動的にスケールアウト(またはダウン)を行ってくれる
- また、ウェアハウスのスケールアップとスケールアウト：Tabjoltというベンチマークツールで色々テストやシミュレーションが出来る。
- 検討するタイミングはどこで取るか：クエリのキュー待ち時間を監視することで見極める
単体クエリの処理性能
- 単体クエリや描画処理がボトルネックになる場合は「ダッシュボードデザインの変更」を検討。
  - ダッシュボードデザインが悪いとパフォーマンスは出ない
  - デザインを変える＝Snowflakeへ発行するクエリを変える
  - これは結果的にTableauの描画性能にも効いてくる
  - BI製品の特性に応じた効率的なダッシュボードデザインを目指そう
Tableauの描画性能
- BI製品のベストプラクティスに沿ったデザインを参考に
  - 効率的に作業できるワークブックの設計
- 改善例の紹介
まとめ
- ライブと抽出を併用することでウェアハウスコストを抑制
- 同時実行性能を向上するマルチクラスターウェアハウス
- ダッシュボードデザインのベストプラクティスの重要性

まとめ

という訳で、SNOWDAY JAPANブレークアウトセッション「ビジネスの意思決定を加速する BI on Snowflake 設計の勘所」のレポートでした。こちらの内容を見ててふと「この課題とソリューション、RedshiftとTableauの組み合わせでも同じ問題に直面してたなぁ...」と昔を思い出しました。RedshiftがSnowflakeに変わっただけで、詰まるところ「ボトルネックになっているところ、解決方法は変わらない」のですね。「このノウハウはどのデータベース／データウェアハウスでも有効である」と言い換えることも出来るのだと思います。必要な情報を確認し、取りうる良策を積極的に取り入れて改善していきたいですね。